By way of background, a content store provides storage for raw contents that are subsequently transformed and displayed to website users as web pages after a transformation process via a server. For web pages in which a high volume of contents are served, read requests to the content store may be load balanced by having multiple instances of the content store. For example, each instance may have a full set of contents capable of handling a subset of the request load.
Although a multiple instances design may solve a website's read load problem, it may create problems with respect to adding, updating, or removing content. Conventionally, content publishers have relied on a file replication tool, which has several undesirable limitations. For example, conventional content publishers do not guarantee data integrity across instances of a content store (i.e., some content may be available on particular instances of the store but not others). Also, since conventional content publishers do not support parallel publishing, concurrent publish requests are undesirably processed in an arbitrary order, one request at the time. To this end, publish time is often unpredictable since concurrent publish requests are arbitrarily processed one at a time. Furthermore, if content is being updated, such content is not available for read for the duration of update.
The above-described deficiencies of current methods are merely intended to provide an overview of some of the problems of conventional systems, and are not intended to be exhaustive. Other problems with the state of the art and corresponding benefits of some of the various non-limiting embodiments may become further apparent upon review of the following detailed description.